home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc19.txt < prev    next >
Text File  |  1994-08-01  |  3KB  |  55 lines
  1. Network Working Group                        John E. Kreznar
  2. RFC-19                                SDC
  3.                                 7 October 1969
  4.  
  5.  
  6.  
  7.      TWO PROTOCOL SUGGESTIONS TO REDUCE CONGESTION AT SWAP-BOUND NODES
  8.  
  9.  
  10.  
  11. There is a wide variance in swap rates between core and auxiliary store
  12. among the HOST systems to be nodes in the ARPA network.  The slower of
  13. these, of which our 360/50 system with 2303 drum swap store is an example,
  14. might improve the utility of the network not only for themselves but for all
  15. nodes if the two protocol suggestions of this note were to be adopted.
  16.  
  17. l.  HOST control of ordering of IMP-to-HOST traffic.  IMP-HOST protocol now
  18.     calls for delivery of messages from IMP to HOST in the order in which
  19.     the IMP received them.  This may lead to wasted swapping, if, for example,
  20.     the IMP has messages for its HOST's timeshare users A and B, in that
  21.     order, at a time when user B is in HOST core.  B would have to be swapped
  22.     out, A in, and the first message accepted--only to discover that now A
  23.     must be swapped out and B back in again.  If the HOST could a) read the
  24.     IMP's queue of waiting messages and b) accept them in the order it found
  25.     most effective, then a new mechanism for improvement of network efficiency
  26.     would be at thand.  Clearly this change would have an impact on BBN's IMP
  27.     software.
  28.  
  29. 2.  Core-to-core transfers between HOSTS.  At another level, perhaps not
  30.     involving HOST-IMP protocol or IMP software changes, is a HOST-HOST
  31.     protocol wherein cooperating HOSTS agree to lock appropriate programs
  32.     in core for the duration of a multi-message file transfer on an auxiliary
  33.     connection.  This could greatly reduce the time to transfer such a file
  34.     to or from a swap-bound HOST.  Unfortunately, the numbers mitigate possible
  35.     advantages of this approach to some extent:  if we assume a 50 kilobit/sec
  36.     line and suppose further that it is dedicated at 100% efficiency to this
  37.     transfer (which may require slightly different handling of RFNMs in this
  38.     case) this comes out to just over 6 8-kilobit messages per second.  It may
  39.     be impolitic in a timeshare environment to lock a single program in core
  40.     for more than abvout 2 seconds.  If this is the case, then the method 
  41.     would be applicable only for the rather limited range of file sizes of 2-16
  42.     messages.  Nevertheless, the time to move a large file could be so greatly
  43.     enhanced by this approach that I think it deserves consideration.
  44.  
  45.  
  46. 1.  Abhi Bhushan, Proj. MAC        10.  Jerry Cole,       SDC
  47. 2.  Steve Crocker, UCLA            11.  John Kreznar,    "
  48. 3.  Ron Stoughton, UCSB            12.  Dick Linde,    "
  49. 4.  Elmer Shapiro, SRI            13.  Bob Long,        "
  50. 5.  Steve Carr, Utah            14.  Reg Martin,    "
  51. 6.  John Haefner, RAND            15.  Hal Sackman,    "
  52. 7.  Paul Rovner, LL            16.  C. Weissman,    "
  53. 8.  Bob Kahn, BB&N            17.  Marty Bleier,    "
  54. 9.  Larry Roberts, ARPA
  55.